# Outline
一、論述
A、待敘項目

# TL;DR
...

# Updated
2019-10-06: 更新標題文章結構

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、論述

依照前面所述的概念，GIt 將每個檔案儲存成 Blob 物件，並且使用 Tree 物件去紀錄路徑。這樣我們就可以比對同一個路徑下紀錄的 Blob 物件是否相同，若是不相同就透過其內建的比對工具去比較兩個檔案的差異。

既然能得到檔案不同之處，那我們也就可以透過比較某個 commit 與其前一個 commit 之間的不同，得出該 commit 變動的 patch，並輸出成檔案方便給其他人套用，這就有點像是其他紀錄差異的版控工具所記錄的資訊，不同的是那些工具是一開始就是紀錄差異，所以在切換分支或是改變當前 commit 時，得一個個套用 patch，速度自然慢。相比之下 Git 是需要知道差異時才進行比較，平時切換分支也不過就是改變參考的 Blob 物件，然後覆蓋到 working directory 罷了。

在 Git 中要產生 patch 就是透過 git diff 和 git format-patch，差別在於前者指生成內容的差異，後者則會紀錄 commit 的相關資訊，像是 Commit SHA-1 值、作者、訊息等等。兩者都可以透過 git apply 或 git am 去套用。

儘管我們可以生成 patch 去套用，但若是想要套用的變動其實就在同一個 Repository，還要透過這樣去落實也顯得麻煩。這時候我們就可以嘗試使用 git cherry-pick，我們可以把他們看成他直接幫我們在當前的 Repository 去進行 git format-patch 和 git apply。當 Git 在進行 Cherry-pick 時，會把目標 commit 的訊息、原作者、變動等資訊都搬過去，最後根據 commit 的實際內容再重新產生一個 SHA-1 直作識別。所以雖然變動是一樣的，但是 Commit 的確是不同的。

而所謂的 git rebase 就可以看作是一次做多個 cherry-pick。互動模式大概就是讓我們在套用前順便先修改部分資訊的概念。

附錄 A、待敘項目

• 透過 git diff 產生 patch
• git format-patch
• 設計實驗與範例程式碼